Support RakNet Cookies #4554
Support RakNet Cookies #4554
Conversation
Signed-off-by: Joshua Castle <[email protected]>
|
You can download test builds from the Checks Tab:
|
rtm516
added
PR: Needs Testing
|
Tested. |
build-logic/src/main/kotlin/geyser.modded-conventions.gradle.kts
Outdated
Show resolved
Hide resolved
|
@MossCG The DOS attack issue was resolved here - this PR just goes a step further with using a cookie to verify that the sender and recipient match to prevent spoofing. If you wish to inform others, please link the following CVE for detailed information: |
|
@MossCG just wanted to clarify in your wireshark screenshot that we are not actually encrypting the RakNet connection with this PR (the connection after login during game play is already encrypted, not using RakNet's builtin encryption scheme). There was an issue in wireshark where it would incorrectly think that the RakNet connection was encrypted based on the first packet requesting security, but this is disabled in the next packet since the Bedrock client does not support full encryption. I had to PR to wireshark to fix this, which was merged: https://gitlab.com/wireshark/wireshark/-/merge_requests/15123. Not sure when it will make it to release. (Just in case you do end up making a post and used that). |
|
Has this problem been completely resolved? The latest version of Geyser that I am currently using has the same issue, which can be viewed as # 4918 |
|
To our knowledge, yes. Please present your findings that makes you think otherwise in that issue or reach out via discord. |
|
The latest version I am currently using still has this issue. Geyser sends a large number of data packets to a player's IP, causing the VPS's upstream bandwidth to run to full capacity, resulting in delayed disconnection for all players. After a while, it will automatically disappear. This situation can occur dozens of times a day. Perhaps the cookie verification fixed and added by Geyser did not work? 目前我用的最新版仍有这个问题，geyser会向某个玩家的IP发送大量数据包，以至于使VPS的上行带宽跑满，玩家全部延迟掉线，过会又会自动消失，这个情况一天可以出现几十次，也许是geyser修复并添加了的cookie验证没起作用? |
|
The cookie verification prevents replies to connections that aren't fully established, but won't do much else after. Please provide more info on the issue you made (logs, a geyser dump, if possible some image showing the network spikes) - but not here on the PR. Thanks! |
Changes
Network
Note this currently pulls from jitpack of my own Network repo pending the merge of Support cookies CloudburstMC/Network#38Merged.Configuration
Geyser.RakOfflinePacketLimitis removed as Network has removed rate limiting before the RakNet connection is in online modeLogging
For Hosts and DDoS Mitigation Providers
This PR makes a change to the initial RakNet handshake. If you or your DDoS mitigation service listens in on this in a way that expects it to conform to a specific format, you will need to adjust those systems to account for this. If Geyser does not recieve the correct cookie from the client, it will provide no further response.
More specifically, the security boolean in
(S -> C) Open Connection Reply 1will now be set to true, have an added 4 byte int cookie directly after, and expect the client to reply with the 4 byte cookie cookie immediately following magic field in(C -> S) Open Connection Request 2. The client will also include a boolean immediately after the 4 byte cookie set to false to indicate that it does not support RakNet encryption.Documentation of this change has also been updated on the RakNet page of wiki.vg (https://wiki.vg/Raknet_Protocol) to include these optional fields and specify their usage.
We have already given the major DDoS mitigation providers mentioned on our wiki (TCPShield, Infinity Filter, CosmicGuard, NeoProtect, and Pufferfish) advanced notice regarding this change, so no action should be needed for users of these services by the time this is merged.
Attached are packet dumps showing the initial connection with and without this change. These can be viewed in Wireshark:
cookie_pcaps.zip